The present invention relates generally to the field of data communications, and more particularly, to the field of serial communications bus controllers and microcontrollers that incorporate the same.
CAN (Control Area Network) is an industry-standard, two-wire serial communications bus that is widely used in automotive and industrial control applications, as well as in medical devices, avionics, office automation equipment, consumer appliances, and many other products and applications. CAN controllers are currently available either as stand-alone devices adapted to interface with a microcontroller or as circuitry integrated into or modules embedded in a microcontroller chip. Since 1986, CAN users (software programmers) have developed numerous high-level CAN Application Layers (CALs) which extend the capabilities of the CAN while employing the CAN physical layer and the CAN frame format, and adhering to the CAN specification. CALs have heretofore been implemented primarily in software, with very little hardware CAL support. Consequently, CALs have heretofore required a great deal of host CPU intervention, thereby increasing the processing overhead and diminishing the performance of the host CPU.
Thus, there is a need in the art for a CAN hardware implementation of CAL functions normally implemented in software in order to offload these tasks from the host CPU to the CAN hardware, thereby enabling a great savings in host CPU processing resources and a commensurate improvement in host CPU performance. One of the most demanding and CPU resource-intensive CAL functions is message management, which entails the handling, storage, and processing of incoming CAL/CAN messages received over the CAN serial communications bus and/or outgoing CAL/CAN messages transmitted over the CAN serial communications bus. CAL protocols, such as DeviceNet, CANopen, and OSEK, deliver long messages distributed over many CAN frames, which methodology is sometimes referred to as xe2x80x9cfragmentedxe2x80x9d or xe2x80x9csegmentedxe2x80x9d messaging. The process of assembling such fragmented, multi-frame messages has heretofore required a great deal of host CPU intervention. In particular, CAL software running on the host CPU actively monitors and manages the buffering and processing of the message data, in order to facilitate the assembly of the message fragments or segments into complete messages.
Based on the above and foregoing, it can be appreciated that there presently exists a need in the art for a hardware implementation of CAL functions normally implemented in software in order to offload these tasks from the host CPU, thereby enabling a great savings in host CPU processing resources and a commensurate improvement in host CPU performance.
The assignee of the present invention has recently developed a new microcontroller product, designated xe2x80x9cXA-C3xe2x80x9d, that fulfills this need in the art. The XA-C3 is the newest member of the Philips XA (eXtended Architecture) family of high performance 16-bit single-chip microcontrollers. It is believed that the XA-C3 is the first chip that features hardware CAL support.
The XA-C3 is a CMOS 16-bit CAL/CAN 2.0B microcontroller that incorporates a number of different inventions, including the present invention. These inventions include novel techniques and hardware for filtering, buffering, handling, and processing CAL/CAN messages, including the automatic assembly of multi-frame fragmented messages with minimal CPU intervention, as well as for managing the storage and retrieval of the message data, and the memory resources utilized therefor. In particular, the XA-C3 CAN module has the unique ability to track and reassemble the packets constituting a fragmented message, completely in hardware, only interrupting the CPU (processor core) once a complete, multi-frame message is received and assembled. This tremendously reduces the processor bandwidth required for message handling, thereby significantly increasing available bandwidth for other tasks, so that system performance is greatly enhanced.
The present invention relates to the techniques employed by the XA-C3 microcontroller for detecting an end-of-message condition, for end-of-message handling, and for generating the appropriate end-of-message interrupt. Fundamentally, the task of responding to the end of a message should be very straightforward. More particularly, the final frame of the message should be stored in the buffer, an interrupt to the processor should be generated, and the software should respond by retrieving the message data from the buffer.
However, this seemingly fundamental task is greatly complicated in the XA-C3 microcontroller, since the XA-C3 CAN module can concurrently assemble many (up to 32) incoming, fragmented messages of varying lengths, whereby up to 32 completed messages can be staged and waiting by the time the processor responds to the initial end-of-message interrupt, i.e., the interrupt issued in response to completion of the first received complete message. A further complication arises by virtue of the fact that it is often appropriate for the software to xe2x80x9cpollxe2x80x9d certain categories of messages on an occasional basis rather than respond to an end-of-message interrupt at the moment messages within one of these categories completes. This implies that some message objects may be set up to generate an end-of-message interrupt, while others are not. Either way, the software must be able to determine at any time whether a complete message is available for all message objects. Further, when an end-of-message interrupt is asserted, the processor must be able to determine quickly and easily which message or messages are complete, i.e., ready for processing.
In designing the XA-C3 microcontroller, the present inventors contemplated and rejected a number of message-complete handling schemes, because these schemes would have required extremely cumbersome, inefficient software code, and/or would have added far too much die area. The present invention, as described below, was conceived and finally adopted as the optimum approach.
The present invention encompasses a CAN microcontroller that supports a plurality of uniquely-numbered message objects, that includes a processor core that runs CAN applications, a plurality of message buffers associated with respective ones of the message objects, and a CAN/CAL module. The CAN microcontroller further includes a plurality of individual message object registers associated with each message object, including at least one control register that contains an interrupt-enable control bit, a receive enable bit, and a transmit enable bit. The CAN microcontroller also includes a plurality of global message object control registers, including at least one message complete status register that contains a plurality of status flag bits for respective ones of the message objects, at least one interrupt flag register that contains a receive complete interrupt flag bit and a transmit complete interrupt flag bit, and a message complete info register that contains a plurality of message object identification bits and a status bit.
The CAN/CAL module includes an acceptance filtering function that performs acceptance filtering on each incoming, multi-frame message by comparing a screener field of the incoming, multi-frame message with an acceptance filter field associated with each message object which has its associated receive enable bit set, wherein the incoming, multi-frame message is accepted if its screener field matches the acceptance filter field of a receive-enabled message object; a message handling function that automatically transfers successive frames of an accepted incoming multi-frame message to the message buffer associated with the matching receive-enabled message object; an end-of-message detection function that detects an end-of-message condition which occurs when the last flame of the accepted incoming multi-frame message has been stored in the message buffer associated with the matching receive-enabled message object; and, an end-of-message detection handling and interrupt generation function that, in response to the detection of the end-of-message condition: sets the status flag bit contained in the at least one message complete status register corresponding to the matching receive-enabled message object; sets the receive complete interrupt flag bit contained in the at least one interrupt flag register, if the interrupt-enable control bit contained in the at least one control register associated with the matching receive-enabled message object is set; and, sets the status bit contained in the message complete info register, if the interrupt-enable control bit contained in the at least one control register associated with the matching receive-enabled message object is set.
A current application running on the processor core can check the status of the status flag bits contained in the at least one message complete status register, at selected times. The current application running on the processor core processes the completed message corresponding to the message object associated with an enabled status flag bit that is contained in the at least one message complete status register.
A current application running on the processor core can also check the status of the status bit contained in the message complete info register to determine whether or not there are any pending completed messages associated with a respective interrupt-enabled message object. In response to a determination that there is a pending completed message based on the status of the status bit contained in the message complete info register, the current application running on the processor core: processes the completed message corresponding to the lowest-numbered receive-enabled message object identified by the message object identification bits contained in the message complete info register; clears the status flag bit contained in the at least one control register associated with the lowest-numbered receive-enabled message object; checks the status of the status bit contained in the message complete info register; and repeats each of the above-recited operations if the status bit contained in the message complete info register is enabled, until the status flag bit is no longer enabled.
The CAN/CAL module generates a message-complete interrupt in response to detection of an end-of-message condition if the interrupt-enable control bit contained in the at least one control register associated with the corresponding receive-enabled message object is enabled. The current application running on the processor core processes the completed message, in response to the message-complete interrupt.